Philipp Kiemle [Wed, 21 May 2025 11:19:36 +0000 (13:19 +0200)]
breakManager: Add l10n comments
Small strings like this often have different possible translations,
depending on their meaning. A comment is needed here to make sure
they are translated correctly.
Florian Müllner [Wed, 21 May 2025 13:42:14 +0000 (15:42 +0200)]
environment: Remove old object.actor compatibility code
The change from plain JS classes with an actor property to
Clutter.Actor subclasses happened over 6 years ago, so
everyone should have adjusted by now.
Damien Tournoud [Tue, 13 May 2025 15:29:59 +0000 (08:29 -0700)]
appDisplay: Clicking outside folders does not consistently close them
This is because the container of the dialog changes sizes after a
refresh, for reasons that are not fully explained. A better condition
is to check explicitly that the click doesn't fall into the dialog.
Mutter now exposes the is_maximized() method for checking for
full maximization, and the plain (un)maximize() methods no
longer cover partial maximization.
Sebastian Keller [Wed, 30 Apr 2025 11:13:41 +0000 (13:13 +0200)]
timeLimitsManager: Don't adjust times for offset changes after resume
The non-continuous change in wall clock time after a suspend/resume
triggers timeChangeNotify which adjusts the stored time data according
to the difference in clock offsets. The monotonic clock however might
not have advanced during the suspend. Since the offsets are the
difference between the wall clock time and monotonic time, the
difference between the old and new offset will be the duration of the
sleep if there was no change in the monotonic clock. Adjusting the time
data by this will move the beginning of the inactive period from the
suspend forward in time to just before the resume, effectively removing
it. Since all previous times are adjusted as well, this will result in
time data as if the system had been running continuously, but was
started later than it actually was.
Fix this by not adjusting times on resume and just updating the current
offset to account for the monotonic clock not advancing during sleep.
Balló György [Mon, 31 Mar 2025 15:12:36 +0000 (17:12 +0200)]
runDialog: Fix launching shell command in terminal
At one point Clutter became stricter when handling keybindings,
and the text's `activate` signal is no longer emitted when
additional modifiers are pressed.
To fix launching a command in the terminal when activating
with ctrl, make the entry non-activatable and move activation
to a `key-press-event` handler.
Takao Fujiwara [Sun, 9 Mar 2025 00:40:36 +0000 (09:40 +0900)]
inputMethod: Check for surrounding text before enabling that capability
While the text input protocol does not have the concept of optional features,
some clients like VTE may lag behind on support for retrieving surrounding
text. This is seen as no surrounding text being set by the client, yet we
invariably enable the SURROUNDING_TEXT capability, giving some IMs the wrong
idea that no text is what there is, thus being free to submit other related
requests like deleting surroundings.
Optionally toggle the SURROUNDING_TEXT capability given the existence of
surrounding text, so that IMs know what to expect on subpar clients. At
a minimum, the surrounding text should be actually the empty string for
empty text fields, on clients that do support it.
Fixes: mutter@27bdf0c577 ("wayland/text-input: Use byte based offset in delete_surrounding_text") Fixes: mutter@33088d59db ("wayland/text-input: Pass char based offset to ClutterInputFocus") Fixes: mutter@fb86d5d5b0 ("wayland/text-input: Reset surrounding text values by focus change")
closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3102
Andy Holmes [Tue, 18 Mar 2025 09:12:06 +0000 (02:12 -0700)]
messageList: Mark NotificationMessageGroup for export
This allows extensions to override `_addNotification()` to create
custom `NotificationMessage` subclasses, which is already possible
for `MessageTray.MessageTray._showNotification()`.
Optional catch bindings have been supported for quite a while now,
so we can treat unused error bindings in catch statements like any
other unused variable.
Florian Müllner [Thu, 13 Feb 2025 13:11:04 +0000 (14:11 +0100)]
loginDialog: Show session menu button when in IN_PROGRESS status
Commit c8bb45b added a new IN_PROGRESS status that replaces FAILED
while the user is still allowed to retry authentication.
We need to account for it when updating the visibility of the
session menu button, otherwise the button disappears after
entering a wrong password.
Fixes: c8bb45b41c ("gdm: Limit verification cancellations to be conform to allowed-failures") Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5784
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3638>
Philip Withnall [Tue, 8 Apr 2025 14:32:36 +0000 (15:32 +0100)]
breakManager: Rework notification urgency setting and presentation
Move the setting of the notification’s urgency, and adding the
notification to the queue, to beside where the notification is created.
This avoids the potential for changing the urgency of an existing
notification if none of the branches above are taken, and
`this._notification` is non-empty.
Spotted by Florian Müllner in
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687#note_2405781.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
Philip Withnall [Tue, 8 Apr 2025 14:28:46 +0000 (15:28 +0100)]
breakManager: Clarify some nextBreakType variables
This doesn’t introduce any functional changes, as
`this._manager.currentBreakType` is set to the value returned by
`this._manager.getNextBreakDue()` when entering `BreakState.BREAK_DUE`.
However, it should make the code a little clearer as now the code refers
to the ’next’ break type rather than the ‘current’ one in the context of
an upcoming break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
Philip Withnall [Wed, 2 Apr 2025 11:32:40 +0000 (12:32 +0100)]
breakManager: Update manager state after settings change
The change of settings may have affected when a break is due. In
particular, `this._breakLastEnd` is modified in `_updateSettings()`,
but `this._state` is not modified correspondingly to transition to/from
a `BREAK_DUE` state (if appropriate).
This could be the cause of the `breakDueAgo should be non-negative`
assertion failure from #8280.
Signed-off-by: Philip Withnall <pwithnall@gnome.org> Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
Philip Withnall [Wed, 2 Apr 2025 11:06:42 +0000 (12:06 +0100)]
breakManager: Make brightness setting function clearer
Confusingly, the `brightness` property of
`ClutterBrightnessContrastEffect` has type `CoglColor`, but the
`set_brightness()` setter takes a single `float`.
We previously chose to use the property setter everywhere for
consistency (see
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655#note_2369353),
but didn’t realise the types don’t match.
GJS optimises `this._brightnessEffect.brightness = foo` into a call to
`clutter_brightness_contrast_effect_set_brightness()`, which means the
type mismatch between the two results in a warning (see
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280).
So, let’s change from a property setter into an explicit method call to
avoid the type ambiguity, at the expense of a bit of clarity from using
the same method to set the initial value and each property animation
step.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
Philip Withnall [Wed, 2 Apr 2025 11:05:43 +0000 (12:05 +0100)]
breakManager: Fix a potential null object dereference
There’s no `else` branch above, so it’s possible for
`this._notification` to be `null` at the bottom of the function
(especially if the user has explicitly closed the previous
notification), so handle that.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8280
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
A type-safe comparision against null can be incorrectly positive with never initialized
variables (undefined).
As spotted in https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3688#note_2407551,
allowing for type coercion avoids this situation.
Jonas Dreßler [Wed, 26 Mar 2025 15:12:19 +0000 (16:12 +0100)]
st/image-content: Don't force preferred content size to texture size
When ClutterImage got merged into StImageContent with commit 64d5d01360
("st: Merge ClutterImage with ImageContent"), a small error slipped in when
copying over the update_image_size() function.
Within ClutterImage, update_image_size() served a simple purpose: To call
clutter_content_invalidate_size() in case the texture size would change.
To check that, ClutterImage was storing the existing texture size in the
priv->width and priv->height fields.
When merging into StImageContent, those priv->width/height fields happened
to overlap with priv->width/height of StImageContent, but there they are
storing the preferred size, rather than the texture size. Copying
update_image_size() as-is into StImageContent meant we now set the
preferred size to the texture size, subtly breaking resource-scaled StIcons
(where texture size is a multiple of the preferred size).
The breakage isn't very apparent because StIcons manually set the size
of their internal ClutterActor child to the requested icon-size via
clutter_actor_set_size() in st_texture_cache_load_gicon(), and that makes
the child actor report the correct size in get_preferred_width/height(). The
child actor gets allocated via clutter_actor_allocate_align_fill() from
ClutterBinLayouts vfunc_allocate(), and clutter_actor_allocate_align_fill()
honors both the available size from the parent and the CONTENT_SIZE
request-mode on the child. So when the StIcon has a larger allocation (aka
extra available size), clutter_actor_allocate_align_fill() will fill that
available space with the (too large) content size.
To reproduce the issue, on a resource-scaled monitor, simply create an
StIcon with a fixed width and height that's larger than the icon-size. The
icon will be painted too large and blurry.
Fix this fallout by avoiding to touch the priv->width/height properties on
StImageContent, and instead simply comparing old texture size to new texture
size, we have both textures around after all!
Sebastian Keller [Wed, 26 Mar 2025 10:28:30 +0000 (11:28 +0100)]
loginManager: Use signal argument to detect preparing for sleep
The DBus PreparingForSleep property on org.freedesktop.login1.Manager
does not trigger PropertyChanged signals, leading to wrong values due to
gdbus caching. In most cases it would have always been false.
Additionally it was not included in the XML interface description file
included in gnome-shell. So it was actually undefined.
Since this property is used in _calculateUserStateFromLogind() to
determine that a user is not active when closing the lid on a laptop,
the user was considered still active.
Fix this by storing the "start" argument from the PrepareForSleep signal
instead of trying to read from the property.
Fixes: 6a43b6f55 ("timeLimitsManager: Store screen time state on suspend/resume") Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3679>
Sebastian Keller [Sun, 23 Feb 2025 11:15:52 +0000 (12:15 +0100)]
slider: Align handle size with with pixel grid
Since the handle radius is used to calculate the width and height of the
slider, having the calculated size be a non-integer value can cause the
following widgets in a box-like container to be unaligned with the pixel
grid, which can lead to blurriness or other visual issues.
This for example could be observed with the interface font set to
"Cantarell 12", which results in a handle radius of 8.278. In quick
settings when showing two consecutive sliders, the second slider then
gets rendered at a non-integer vertical offset.
Further having a non-integer size for a StDrawingArea can cause the
texture to get slightly squished or stretched as the size of the cairo
surface is rounded to the nearest pixel, but rendered using the
unrounded actor size.
This commit changes the border radius rather than ceiling the preferred
width/height so that the handle size always matches the width or height
of the widget and there are no visual gaps caused by a partially filled
pixel.
Sebastian Keller [Thu, 20 Feb 2025 22:31:05 +0000 (23:31 +0100)]
slider: Use correct handle size when calculating rightmost position
Using the ceiled radius for calculating the rightmost position the
handle can take on the slider was resulting in a small gap when the size
was not an integer value since the radius used when drawing the handle
is not ceiled.
This effectively reverts 38da479e which seems to have been the wrong fix
for the problem it was trying to solve. The problem presumably had been
caused by not considering the border that the handle still had at that
time.
The border issue was then later fixed by 3ddae9d8, without reverting 38da479e. Then in 6fd0aac8 support for drawing borders on the slider got
dropped, including the changes from 3ddae9d8, leaving us with just the
changes from 38da479e but now without borders on the handle.
Florian Müllner [Sun, 16 Mar 2025 00:57:55 +0000 (01:57 +0100)]
status/bluetooth: Disconnect device signals on destroy
Devices may outlive the corresponding menu item, for example on
shutdown. Make sure that signals are disconnected correctly in
that case to avoid warnings.
Philip Withnall [Wed, 5 Mar 2025 11:32:48 +0000 (11:32 +0000)]
timeLimitsManager: Remove a redundant fallback value
This code was originally copied from `lightbox.js`, where the fallback
is potentially useful because the duration is provided as an argument.
The `timeLimitsManager` uses a constant as the duration, though, so the
fallback is just confusing.
Spotted in https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655#note_2369352
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655>
Philip Withnall [Mon, 3 Mar 2025 18:31:28 +0000 (18:31 +0000)]
breakManager: Switch from lightbox to a Clutter effect for fading out
From some testing on a full session with break reminders enabled, it
seems that it’s possible to break the stacking order of the lightbox
actor if the user continues to interact with the session while it’s
visible (for example, while they’re supposed to be taking a movement
break).
Rather than try and work out what’s going on with the lightbox here, it
seems more robust to switch to using a Clutter effect, like we did with
the screen time UI (in `timeLimitsManager`). Then the effect can be
applied to the main UI group, and doesn’t depend on a separate actor
being placed in the right place in the scene graph.
So, remove the lightbox, and instead add a
`ClutterBrightnessSaturationEffect`, and use its brightness property to
fade the screen slightly while in breaks.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655>
Philip Withnall [Mon, 3 Mar 2025 18:48:10 +0000 (18:48 +0000)]
breakManager: Allow break to be taken or delayed when overdue
This makes the buttons on the ‘break overdue’ notification match those
on the ‘time to take a break’ notification. This makes more sense than
showing no buttons on the former, because it leads on from the ‘time to
take a break’ notification after a short wait.
By adding a ‘Take’ button it gives the user a path to acknowledge that
they are starting to take their break, rather than having to let the
session idle.
The ‘break overdue’ notification wasn’t on the original design[1], which is
probably why its buttons got overlooked.
projects / gnome-shell.git / log